Various forms of databases for storing information exist very often in our increasingly computerised world. Information is usually structured in the database in the form of objects which, for instance, may represent a physical article whose properties are stored in the database.
When transferring the physical reality to a database, software comprising a graphical interface is often used, models being drawn into a coordinate system and stored in the database by the software. This is called “writing” or “entering” the model into the database. One or more models are linked to an object, which may also be linked to information about the properties, choice of material, etc. of the object. The geometric models and other properties are stored in documents that are linked to an object by means of references to an object ID. This type of system is well known in CAD (Computer Aided Design), for instance.
The information in the database is used in calculations performed by the designer, such as strength calculations, optimisation calculations, collision analyses, etc. When the space is large in relation to the object, the number of objects may be extremely large. One problem arising out of this is that, before each calculation, the system takes all the objects in the space into consideration. This is often completely wasted effort since normally only a few neighbouring objects affect a calculation that is being performed.
Considerable differences may also exist between the degree of detail for different objects. A flat wall may perhaps be modelled sufficiently well by a single object, say a rectangular parallelepiped. A clock hanging on the wall, on the other hand, may be accurately modelled and therefore contain a large number of small components.
A traditional solution to this problem is for the system to divide the objects into hierarchical levels or scales. Small parts are grouped in a combined object that can be represented with less information. The clock may contain a number of objects on a smaller scale, for instance, all of which represent a particular component in the clock. On a larger scale the whole clock is represented by a single object corresponding only to its outer geometry, for instance. The smaller scale is “hidden” from a designer working on the larger scale since he/she only needs to make use of relations between objects on the larger scale. Similarly, the relations on the larger scale are deactivated when work is being performed on the smaller scale.
This manner of handling the problem is unsatisfactory for several reasons. In the first place, the user can only work in one scale at a time, which entails problems when properties of an object influence objects on a smaller or larger scale. For example: if the clock mentioned above has a suspension hook in the smaller scale, this may affect the force that in the larger scale holds the clock on the wall. A change in the hook thus affects a relation higher up in the hierarchy. This relationship is not apparent if the work is limited to one scale at a time.
In the second place, it is difficult to draw limits as to which objects may be permitted on a particular scale. Different applications may have different suitable divisions, resulting in deficient or non-existent compatibility.
According to known technology the space is divided into a large number of part-volumes which are stored in the database. Each object may extend into several part-volumes and, for each part-volume, the database stores which objects are at least partially in this part-volume. In this case a calculation performed for one point in the space need only be affected by information relating to objects in the small part-volume that includes the relevant point. Naturally, if the calculation relates to an object extending over several part-volumes, information from the objects in all these part-volumes is involved. On the other hand, information relating to objects located in part-volumes entirely separate from the relevant part-volume need not be included in the calculation, and the system therefore avoids numerous unnecessary operations.
The drawback with this system is that it is completely static. In a volume with a few large objects, such as a wall, a large number of part-volumes will only contain reference to a single object. However, in the case of an object with many small parts, such as a clock, a part-volume may contain a very large number of references. Consequently, a calculation such as a collision calculation, performed somewhere on the wall, will comprise considerably more calculation phases if it is performed for any of the part-volumes near the clock than if it is performed for an empty wall surface, although the calculation is not necessarily affected by the clock.
It could be said that the system solves the problem of different hierarchical levels by locking the entire coordinate system to a specific level that is assumed to be sufficiently small. Unfortunately, problems arise with part-volumes containing information of very different type—quite simply an unbalance in the mathematics defining the coordinate system and the objects placed in it. This results in extremely demanding calculations for collision or optimisation analysis, for instance.